web2py

The Python language

It is also possible to write variables into strings in various ways:

>>> print 'number is ' + str(3)
number is 3
>>> print 'number is %s' % (3)
number is 3
>>> print 'number is %(number)s' % dict(number=3)
number is 3

Overview

When dates are converted to strings in forms they are converted using the ISO representation

%Y-%m-%d %H:%M:%S

response.body: a StringIO object into which web2py writes the output page body. NEVER CHANGE THIS VARIABLE.
response.cookies: similar to request.cookies, but while the latter contains the cookies sent from the client to the server, the former contains cookies sent by the server to the client. The session cookie is handled automatically.
response.download(request, db): a method used to implement the controller function that allows downloading of uploaded files. response.download expects the last arg in request.args to be the encoded filename (i.e., the filename generated at upload time and stored in the upload field). It extracts the upload field name and table name as well as the original filename from the encoded filename. response.download takes two optional arguments: chunk_size sets the size in bytes for chunked streaming (defaults to 64K), and attachments determines whether the downloaded file should be treated as an attachment or not (default to True). Note, response.download is specifically for downloading files associated with db upload fields. Use response.stream (see below) for other types of file downloads and streaming. Also, note that it is not necessary to use response.download to access files uploaded to the /static folder -- static files can (and generally should) be accessed directly via URL (e.g., /app/static/files/myfile.pdf).
response.files: a list of .css, .js, .coffee, and .less files required by the page. They will automatically be linked in the head of the standard "layout.html" via the included "web2py_ajax.html". To include a new CSS, JS, COFFEE, or LESS file, just append it to this list. It will handle duplicates. The order is important.
response.include_files() generates html head tags to include all response.files (used in "views/web2py_ajax.html").
response.flash: optional parameter that may be included in the views. Normally used to notify the user about something that happened.
response.headers: a dict for HTTP response headers. Web2py sets some headers by default, including "Content-Length", "Content-Type", and "X-Powered-By" (set equal to web2py). Web2py also sets the "Cache-Control", "Expires", and "Pragma" headers to prevent client-side caching, except for static file requests, for which client-side caching is enabled. The headers that web2py sets can be overwritten or removed, and new headers can be added (e.g., response.headers['Cache-Control'] = 'private'). You can remove a header by removing its key from the response.headers dict, e.g. del response.headers['Custom-Header'], however web2py's default headers will be re-added just before returning the response. To avoid this behavior, just set the header value to None, e.g. to remove the default Content-Type header, response.headers['Content-Type'] = None
response.menu: optional parameter that may be included in the views, normally used to pass a navigation menu tree to the view. It can be rendered by the MENU helper.
response.meta: a Storage object that contains optional <meta> information like response.meta.author, .description, and/or .keywords. The content of each meta variable is automatically placed in the proper META tag by the code in "views/web2py_ajax.html", which is included by default in "views/layout.html".
response.include_meta() generates a string that includes all response.meta headers serialized (used in "views/web2py_ajax.html").
response.postprocessing: this is a list of functions, empty by default. These functions are used to filter the response object at the output of an action, before the output is rendered by the view. It can be used to implement support for other template languages.
response.render(view, vars): a method used to call the view explicitly inside the controller. view is an optional parameter which is the name of the view file, vars is a dictionary of named values passed to the view.
response.session_file: file stream containing the session.
response.session_file_name: name of the file where the session will be saved.
response.session_id: the id of the current session. It is determined automatically. NEVER CHANGE THIS VARIABLE.
response.session_id_name: the name of the session cookie for this application. NEVER CHANGE THIS VARIABLE.
response.static_version: a version number for the static asset management with response.files.
response.static_version_urls: setting this to True enables static asset management on any link to the static folder.
response.status: the HTTP status code integer to be passed to the response. Default is 200 (OK).
response.stream(file, chunk_size, request=request, attachment=False, filename=None): when a controller returns it, web2py streams the file content back to the client in blocks of size chunk_size. The request parameter is required to use the chunk start in the HTTP header. file should be a file path (for backward compatibility, it can also be an open file object, but this is not recommended). As noted above, response.download should be used to retrieve files stored via an upload field. response.stream can be used in other cases, such as returning a temporary file or StringIO object created by the controller. If attachment is True, the Content-Disposition header will be set to "attachment", and if filename is also provided, it will be added to the Content-Disposition header as well (but only when attachment is True). If not already included in response.headers, the following response headers will be set automatically: Content-Type, Content-Length, Cache-Control, Pragma, and Last-Modified (the latter three are set to allow browser caching of the file). To override any of these automatic header settings, simply set them in response.headers before calling response.stream.
response.subtitle: optional parameter that may be included in the views. It should contain the subtitle of the page.
response.title: optional parameter that may be included in the views. It should contain the title of the page and should be rendered inside the html title tag in the header.
response.toolbar: a function that allows you to embed a toolbar into page for debugging purposes {{=response.toolbar()}}. The toolbar displays request, response, session variables and database access time for each query.
response._vars: this variable is accessible only in a view, not in the action. It contains the values returned by the action to the view.
response._caller: this is a function that wraps all action calls. It defaults to the identity function, but it can be modified in order to catch special types of exception to do extra logging;
```
response._caller = lambda f: f()
```
response.optimize_css: can be set to "concat,minify,inline" to concatenate, minify and inline the CSS files included by web2py.
response.optimize_js: can be set to "concat,minify,inline" to concatenate, minify and inline the JavaScript files included by web2py.
response.view: the name of the view template that must render the page. This is set by default to:
```
"%s/%s.%s" % (request.controller, request.function, request.extension)
```
or, if the above file cannot be located, to
```
"generic.%s" % (request.extension)
```
Change the value of this variable to modify the view file associated with a particular action.
response.delimiters defaults to ('{{','}}'). It allows you to change the delimiter of code embedded in views.
response.xmlrpc(request, methods): when a controller returns it, this function exposes the methods via XML-RPC^[xmlrpc] . This function is deprecated since a better mechanism is available and described in Chapter 10.
response.write(text): a method to write text into the output page body.
response.js can contain Javascript code. This code will be executed if and only if the response is received by a web2py component as discussed in Chapter 12.
response.models_to_run contains a list of regexes that chooses what models to run.
- By default, this is set automatically to load /a/models/*.py, /a/models/c/*.py, and /a/models/c/f/*.py files when /a/c/f is requested. You can set, e.g., response.models_to_run = ['myfolder/'] to force the execution only of the models inside your application's models/myfolder subfolder.
- NB: response.models_to_run is a list of regex, not a list of filepaths. The regex are relative to the models/ folder, so any model file with a relative file path that matches one of the regexes will be executed. Note also that this can not affect any models which have already been evaluated because they were earlier in the alphabetic sort order. That is, if a conditional model for controller orange was orange/orange_model.py and it set the regex to [.*], that change does not affect any models previously rejected for loading such as the model apple/apple_model.py ; it matches the new regex, but it was evaluated and rejected before orange/orange_model.py changed the regex.
- This means that if you want to use models_to_run to share conditional models between controllers, put the models in a sub-directory that will sort last such as zzz, and then use a regex 'zzz'.

>>> db.define_table('person', Field('name'))
<Table person (id, name)>
>>> def pprint(callback, *args):
...     print "%s%s" % (callback, args)
... 
>>> db.person._before_insert.append(lambda f: pprint('before_insert', f))
>>> db.person._after_insert.append(lambda f, i: pprint('after_insert', f, i))
>>> db.person.insert(name='John')
before_insert(<OpRow {'name': 'John'}>,)
after_insert(<OpRow {'name': 'John'}>, 1L)
1L
>>> db.person._before_update.append(lambda s, f: pprint('before_update', s, f))
>>> db.person._after_update.append(lambda s, f: pprint('after_update', s, f))
>>> db(db.person.id == 1).update(name='Tim')
before_update(<Set ("person"."id" = 1)>, <OpRow {'name': 'Tim'}>)
after_update(<Set ("person"."id" = 1)>, <OpRow {'name': 'Tim'}>)
1
>>> db.person._before_delete.append(lambda s: pprint('before_delete', s))
>>> db.person._after_delete.append(lambda s: pprint('after_delete', s))
>>> db(db.person.id == 1).delete()
before_delete(<Set ("person"."id" = 1)>,)
after_delete(<Set ("person"."id" = 1)>,)
1

:code - The optional second argument turns the INSERT form into an UPDATE form for the specified record (see next subsection).showid:inxx delete_label:inxx id_label:inxx submit_button:inxx - Ifdeletable is set to True, the UPDATE form displays a "Check to delete" checkbox. The value of the label for this field is set via the delete_labelargument. -submit_buttonsets the value of the submit button. -id_labelsets the label of the record "id" - The "id" of the record is not shown ifshowid is set to False. -fields is an optional list of field names that you want to display. If a list is provided, only fields in the list are displayed. For example: fields = ['name'] :code -labels is a dictionary of field labels. The dictionary key is a field name and the corresponding value is what gets displayed as its label. If a label is not provided, web2py derives the label from the field name (it capitalizes the field name and replaces underscores with spaces). For example: labels = {'name':'Your Full Name:'} :code -col3 is a dictionary of values for the third column. For example: col3 = {'name':A('what is this?', _href='http://www.google.com/search?q=define:name')} :code -linkto and uploadare optional URLs to user-defined controllers that allow the form to deal with reference fields. This is discussed in more detail later in [[Links to referencing records #Links-to-referencing-records]] and [[SQLFORM and uploads #SQLFORM-and-uploads]] sections respectively. -readonly. If set to True, displays the form as readonly -comments. If set to False, does not display the col3 comments -ignore_rw. Normally, for a create/update form, only fields marked as writable=True are shown, and for readonly forms, only fields marked as readable=True are shown. Setting ignore_rw=Truecauses those constraints to be ignored, and all fields are displayed. This is mostly used in the appadmin interface to display all fields for each table, overriding what the model indicates. -formstyle:inxx [[formstyle]] formstyle determines the style to be used when serializing the form in html. The default value is sourced from response.formstyle, currently it is "bootstrap4_inline". Other options are "bootstrap4_stacked", "bootstrap3_inline, "bootstrap3_stacked", "bootstrap2", "table3cols", "table2cols" (one row for label and comment, and one row for input), "ul" (makes an unordered list of input fields), "divs" (represents the form using css friendly divs, for arbitrary customization), "bootstrap" which uses the bootstrap 2.3 form class "form-horizontal". formstylecan also be a function which generates everything inside the FORM tag. You pass to your form constructor function two arguments, form and fields. Hints can be found in the source code file sqlhtml.py (look for functions named formstyle_) -buttons:inxx buttons is a list of INPUTs or BUTTONs (though technically could be any combination of helpers) that will be added to a DIV where the submit button would go. For example, adding a URL-based back-button (for a multi-page form) and a renamed submit button: buttons = [BUTTON('Back', _type="button", _onClick="parent.location='%s'" % URL(...), BUTTON('Next', _type="submit")]

:code
or a button which links to another page:

buttons = [..., A("Go to another page", _class='btn', _href=URL("default", "anotherpage"))] :code -separator:inxx separator sets the string that separates form labels from form input fields, if set to None the default value is sourced from response.form_label_separator- extra_fields:inxx extra_fields is a list of extra Fields to add. - Optionalattributes are arguments starting with underscore that you want to pass to the FORM tag that renders the SQLFORM object. Examples are: _action = '.' _method = 'POST' ``:code

from gluon.contrib.login_methods.rpx_account import RPXAccount
auth.settings.actions_disabled=['register', 'change_password', 'request_reset_password']
auth.settings.login_form = RPXAccount(request,
    api_key='...',
    domain='...',
    url = "http://your-external-address/%s/default/user/login" % request.application)

Services

@auth.requires_login() @request.restful() def api(): def GET(s): return 'access granted, you said %s' % s return locals() ``

{{
response.files.insert(0, URL('static', 'js/jquery.js'))
response.files.insert(1, URL('static', 'css/calenadar.css'))
response.files.insert(2, URL('static', 'js/calendar.js'))
response.include_meta()
response.include_files()
}}
<script type="text/javascript"><!--
    // These variables are used by the web2py_ajax_init
        // function in web2py.js (which is loaded below).
    var w2p_ajax_confirm_message =
        "{{=T('Are you sure you want to delete this object?')}}";
    var w2p_ajax_date_format = "{{=T('%Y-%m-%d')}}";
    var w2p_ajax_datetime_format = "{{=T('%Y-%m-%d %H:%M:%S')}}";
//--></script>
<script src="{{=URL('static', 'js/web2py.js')}}"
        type="text/javascript"></script>

Components and plugins

The controller belonging to the submitting component needs to send javascript back, so just add this to the existing controller code when processing the submit:

if form.process().accepted:
...
    if request.vars.reload_div:
        response.js =  "jQuery('#%s').get(0).reload()" % request.vars.reload_div

top

web2py

Complete Reference Manual, 6th Edition (pre-release). written by Massimo Di Pierro in English

Search

Table of Contents

The Python language

Overview

The core

The database abstraction layer

Forms and validators

Access Control

Services

jQuery and Ajax

Components and plugins